On initrecs
~~~~~~~~~~~
Initrec is an "init record", corresponding to one line in inittab
(process-describing line that is) or a single file in an initdir.
In the code it is called struct initrec.
Each initrec holds at most one pid.

There are two principal kinds of initrecs: respawning (s-type, services)
and run-once (r-type). Respawning is determined by C_ONCE flag internally.

	new     sysvtab     respawn  exclusive   type
	-------+-----------+--------+-----------+------
	S	service     yes      no          s-type
	L	last        yes      yes         s-type
	R	once        no       no          r-type
	W	wait        no       yes         r-type

Respawn determines how init should react when process dies
"unexpectedly", as opposed to being killed by init.

Exclusive means init should not start (r) or kill (s) anything
else while this particular process is running (r) or dying (s).

Note F is the same as S (the difference is in timing, not in the
way respawning is handled) and X is the same as R with reversed
runlevel mask.


Same uniform list for r- and s-type initrecs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sninit keeps all initrecs in the same list, using the same initrec structures,
and has to loop through all of them even while sitting in a single runlevel.

The alternative is to keep a list of s-type records separately,
and only check for r-type records when switching runlevels.

There is no clear answer here, not for me at least, but uniform
list is clearly simpler and the price (both cpu and mem) looks negligible.
One clear advantage of uniform list is that it allows starting some
services before performing r-type tasks:

	mount   W   /sbin/mount -a
	syslog  S   /sbin/syslogd
	        R   /sbin/setkeys
	        R   /sbin/setup-network ...

and so on. This way, syslogd will have a chance to come up before anything
significant takes place, and thus to save some messages that otherwise could
have been lost.

Note: will have _a_chance_ to come up.
Trying to make sure syslogd is up and running is a bad idea in my opinion;
see dependencies.txt.


Startup entries
~~~~~~~~~~~~~~~
Both sysvinit and busybox init can drop entries that are only used to
bring the system up (that is, to switch from runlevel 0 to some other runlevel).

It is possible for sninit, too, but more difficult due to different memory
allocation model. And if implemented, it will probably consume more space
in the code than it will save in data.

One clear way to do it is to mimic reconfiguration, copying cfgblock
to newblock while filtering out entries not needed anymore.

Another option is moving initrecs within cfgblock.
This currently requires both tricky pointer work, and initrec length field.
Or dropping pointers altogether and using offsets only, but this approach
has its own drawbacks.


Running parallel chains
~~~~~~~~~~~~~~~~~~~~~~~
As in
	(p1; p2; p3) &
	(p4; p5; p6) &
and waiting for them to finish.
Currently sninit only allows this by putting "p1; p2; p3" in a shell script,
"p4; p5; p6" in another script and running the scripts as e-type entries.

I can't see a simple solution here, so it's left unimplemented for now.


Internal inittab: list vs array
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(early versions had singly-linked list of initrecs)

Initial reason for change: any viable L-type entry implementation
needs reverse traversal of the inittab.

This is only part true, it it possible to implement L with two top-to-bottom
passes and little code size increase.
Or using double-linked list, but that results in pretty ugly code.

Subsequent reasoning: init has a lot of a argv-style structures.
So why not use pointers array for inittab as well.

As an added bonus, using arrays removes interconnecting stuff from initrec,
leaving the structure clean.
